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Sir: 



Applicants request a Pre- Appeal Brief Review of the rejections of claims 1, 2, 10, 13 and 14, 
which are based on clear error of fact and omission of essential elements to establish a prima facie 
rejection. 

Applicants are convinced the Examiner is mis-interpreting the present claims and mis- 
applying the claim elements to the Pajak et al. publication. 
A. Present Application 

In an example of the present application, the intent is to find design files that are located 
somewhere in a directory structure within a first environment (e.g., a hardware description 
environment), create a list of those files, and feed them to a tool in a second environment. In one 
example, and contrary to Pajak , the need for hard-coded paths in shell script usage is removed. For 
example, RTL files could be located in several sub-directories in the directory structure and a 
designer may want to synthesize them to create a gate-level netlist. The .rmk files are used to 
define which files are the RTL files. In general, the tool finds these .rmk files, figures out which 
design files are the RTL files (or whichever design files have been requested to be found/gathered), 
and returns a list of the RTL files including the full path name to the design file in the existing 
directory structure within the first environment so that list can be fed to and used by the synthesis 
tool in the second environment for accessing the design files. 

Referring to claim 1, the directory structure is parsed to locate file paths to the description 
files. Also, the description files are parsed to identify file paths to the design files that are defined 
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by the description file. An index is generated, which correlates each description file and its 
respective file path in the first environment. 

A list of the design files is constructed, which contains design file names and respective full 
file paths for each of the design files in the first environment. The respective full file paths are 
constructed by concatenating the file path of the description file that is identified in an index to the 
file path of the design file that is defined by the description file. 

Thus, in the example discussed above, the synthesis tool (in the second environment ) 
accesses at least one of the design files within the first environment through the respective full file 
path to the design file in the first environment. This full file path was produced by concatenating 
the file path of the description file identified in an index to the file path of the design file defined by 
the description file. 

B. Pajak et al. U.S. Publication No. 2003/0145286A1 

Pajak discloses a self-contained embedded test design environment and environment setup 
utility, which is different from the inventions recited in the claims of the present application. In 
Pajak, the user takes a user created file and runs the environment setup utility to get a template for 
this file, called a workspace configuration file. The designer then edits the configuration file. 
Figures 9-11 show examples of the configuration file. 

When the user runs the setup utility, it creates directories (Figure 8-repository generator 
212), creates links (Figure 8-soft link generator 218), and creates the makefiles (Figure 8-process 
control file generator 214), etc. 

The user runs the makefiles (process control files) to perform the function desired (test 
insertion, verification, etc.). Or the user can do a 'make all', that runs everything. This is the same 
as the user running the individual makefiles in the proper order. 

C. Differences Between Pajak and An Example Embodiment of the Present 
Application 

Without focussing on the claims for the moment, the Pajak system is much different than 
that disclosed in the present application, according to at least one embodiment (referred to as "the 
present disclosure"). The following section should be used as an example for background 
information and not to limit any particular claim. 

These differences include: 
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1. The present disclosure parses the directory structure of a system, finding the .rmk files 
(description files) to define the path from the root directory for files. Pajak has the user define paths 
in the workspace configuration file (see e.g., "<HierarchicalFilePath>" in Figure 10). In the present 
disclosure, the description files specify the files and possibly the path to the file relative to the 
description file location, but not the full path to the design files from the root directory of the 
system. 

2. The present disclosure creates an index file that correlates the full paths and files. 

3. Contrary to Pajak, the present disclosure does not create a directory structure (the repository) 
and set up links. The present disclosure does not need the links because it has the index file, etc. 

4. Pajak says their system is portable because the repository can be moved using tar -h. The 
command, "tar" represents "create tape archive". The tar -h option will (as described from the 
UNIX manual "man" page): "Follow symbolic links as if they were normal files or directories. 
Normally, tar does not follow symbolic links." 

So the user gets all the files in the tarbar instead of links that will not resolve when the user 
"untars" it somewhere else. In contrast, the present disclosure is portable wherein the user can 
move it, remove the index file, and let the index file be regenerated to find everything that is now in 
the new location. 

5. Pajak suggests their system can use relative paths in their make files (processor control 
files). This works because Pajak sets up the links in the setup utility . . . because a user had to 
define the hard/complete paths in the workspace configuration file. As described above, the user of 
the present disclosure does not need to define the hard/complete paths. The location of the 
description files will define the paths. 

D. Examiner's Comments Regarding Claim 1 

The Examiner cited various paragraphs and figures in an effort to support the rejection of 
claim 1. These citations are discussed below. 

Regarding claim 1, step a), Pajak [0035] is just saying that they have a variety of files that 
need to be stored and a directory structure needs defined to store these files (Figure 4). 

Regarding step b), claim 1 refers to parsing the directory structure to find the description 
files, whereas Pajak [0091] refers to parsing the input workspace configuration file and creating the 
directories, links & makefiles. So different things are going on. The only commonality is the use of 
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the term "parse". 

Specifically, step b) requires: 

parsing the directory structure " to locate the description file " and 
parsing " the description file to identify file paths to . . . each of the design files 
defined by the description file ." 

Pajak[0091] states, 

When the utility is executed, the utility reads and parses the input file and creates a 
workspace according to the contents of the input file, i.e., a workspace containing 
grouped directories and makefiles for automating many steps in the embedded test 
design flow. 

So, Pajak creates a workspace containing grouped directories and makefiles. Pajak does not 
disclose parsing a directory structure to locate a description file OR parsing that description file to 
identify file paths of design files defined by that description file. 

Regarding step c), claim 1 refers to creating an index file that correlates each description file 
and its respective file path for the first environment. Pajak [0109] refers to running the top-level 
makefile (processor control file) with a target of "All" to cause all the lower-level makefiles to be 
run in the correct order. Applicants do not understand the relationship the Examiner is trying to 
make with respect to step c) of claim 1. Where in Pajak is the alleged "index file" that is generated 
according to claim 1, step c)? 

Regarding step d), claim 1 refers to "constructing a list containing design file names and 
respective full file paths for each of the design files in the first environment." Recall that the design 
files are defined by the description file, as recited in step b). 

Pajak [0122] refers to what is in the input file and how the generators use this - to create 
corresponding directories ("A Design Environment Options section . . . defines . . . parameters 
including a name for each of predetermined design files and libraries and a corresponding path to a 
location of the design data.") 

Step d) of claim 1 further states that the full file paths for each of the design files in the list 
as being " are constructed by concatenating the file path of the description file that is identified in the 
index to the file path of the design file that is defined by the description file ." As described above, in 
the present disclosure, the description files specify the design files and the path to the design files 
relative to the description file location , but not the full path from the root directory of the system. 
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Pajak does not disclose constructing the full file paths as specified in claim 1, i.e., by 
concatenating. 

The Examiner merely found the term "concatenating" in Pajak, but this term has nothing to 
do with Applicants' claims. Pajak [122] refers to "provides ... the location of its concatenated 
netlist . . .." Thus, it is the netlist that is concatenated (i.e., for a "complete circuit design" [0061]). 
As the Examiner is well-aware, a netlist is a list of circuit elements in a design which specifies 
physical connections or "nets" between various inputs and outputs of the circuit elements. 

This paragraph has nothing to do with concatentating file paths of design files, much less in 
the manner recited in claim 1. Specifically, Pajak does not disclose concatenating the file path of the 
description file that is identified in the index to the file path of the design file that is defined by the 
description file, as recited in claim 1 . 

Regarding step e), claim 1 refers to accessing the design file by a design tool in a second 
environment. The Office Action cites paragraphs [0081], [0082], [0122] and Figure 10. Applicants 
believe the Examiner is trying to pull paragraphs from Pajak that show the user input file being used 
to make the directories and links. The difference is that the present disclosure uses the design file of 
interest, while Pajak is just setting up the directories, links and makefiles with relative paths so that 
the user can then run the makefiles to do something useful. With the present disclosure, for 
example, the user does not need to create the links and does not create directories to be able to 
access the design files. Rather, the present disclosure parses directories and makes an index file, not 
links, for example. 

E. Claims Not Anticipated By Pajak 

For at least the foregoing reasons, Pajak does not anticipate each and every element of claim 

1, or of claims 2, 10, 13 and 14 for similar reasons. 

Respectfully submitted, 
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